Identity management in its widest sense means management of all the personal information about a person, including at least all the person's digital relations. Over the next decade, identity management systems in this wide sense are likely to evolve. Short-term, identity management is typically said for web single sign-on with the transfer of a small amount of data about a person.
The main business case is a general boost of electronic business: Identity management is an infrastructure issue where a standard, like the Internet and web standards, may benefit almost all parties.
Single sign-on enables a person or user to log in to different organizations while remembering only one password without allowing all the organizations to impersonate the person towards each other as simply as using the same password directly with all organizations would.
Recently, identity management, in particular single sign-on, are known, for example, by the Liberty Alliance (URL: [intentionally broken up]                http://followed by        www.followed by        projectliberty.org)or by Microsoft Corporation's Passport system (URL: [intentionally broken up]        http//followed byfollowed by:        passport.com)        
The so-called Passport system or short Passport of Microsoft Corporation is a web service operated exclusively by Microsoft Corporation that allows users to sign in to web sites and conduct e-commerce transactions. Less exclusive operations have been promised, but not revealed. Passport currently includes an authentication service, a specialized authentication service just for kids, and an express purchase service.
Older system types related to identity management are classical single sign-on products, public-key infrastructures, and form fillers.
However, none of known products and proposals can, in the interoperable way needed for a global information society and general electronic business in particular, adapt to all the different requirements that the various participants in this information society And electronic business have. Particularly, all prior products and proposals fail to fulfill at least one of the following requirements, as explained below in more detail:    1. Suitability for a free choice of location entities that hold identity-related information about a person, including location entities under the respective user's own physical control, so-called local wallets, and including that multiple location entities hold information of one person.    2. Suitability for browser-only clients and even users that access the system via varying browsers, while not making it necessary for them to do all their browsing through a location entity in a proxy role, which would enable the location entity to see all the user's message contents. Clearly the browser-only users and those with local wallets are not the same—the requirement is that the server's method interoperates with both.    3. Suitability for the transfer of both authentication information and other identity-related information, where the latter may be both freely chosen by the user, such as preferences, or in need of third-party confirmation.    4. Suitability for users that want to remain anonymous, while still allowing the transfer of some identity related information, such as preferences or demographic information.    5. Flexible privacy policies for the release of identity related information.
It may be helpful to discuss the benefits of an identity management system fulfilling these requirements, hereafter abbreviated as Req.: Req. 1 is made by companies like employers and banks who want to act as location entities for their employees or customers at least in relationships related to their business. Moreover, whether persons will embrace identity management voluntarily now is not as clear as one might be led to believe. Currently, the fear of “putting all eggs in one basket” and privacy and trust concerns outweigh the perceived benefit of both single sign-on and simplified form filling for most people. Here again, free choice as in Req. 1 may help, in particular to allow the “local” location entities for the user's truly personal information. These latter concerns also motivate Req. 4. Req. 2 is made for practicality, both because many users cannot be made to install additional software and because some users use the information society infrastructure from varying Internet kiosks and the like. The Internet kiosk is contemplated as a public computer, e.g., in an Internet cafe. Req. 3 is for general applicability and user friendliness, e.g., to allow, with just one system, the restriction of access to certain information and certain operations only to certain users, and also the transfer of addresses, shipping information etc. to business partners. The benefit of the last part of Req. 3 and Req. 5 can be seen as follows: Transferring a small amount of data aims at standard e-commerce applications, where data like shipping and billing information are needed often and quite independent of the communication partner. In extensions to more specific data such as book and travel preferences, one will have to distinguish the partners better. Long-term comprehensive solutions will include data that need third-party confirmation; they will also manage transaction data, e.g., the person's receipts obtained from these partners; and they will integrate with other personal applications, such as a tax declaration using these receipts. Furthermore, long-term solutions will integrate person-to-person applications like calendar sharing, and business-to-business applications such as accessing services for which one's employer has subscribed.
Classical single sign-on schemes and products contain a variety of login scripts or passwords for many applications. For example, U.S. Pat. No. 5,944,824 discloses a system and method for single sign-on to a plurality of network elements. This does not allow browser-only clients unless by using a proxy (cf. Req. 2). Moreover, it only covers authentication information, not other identity-related information (cf. Req. 3), and thus also no privacy policies (Req. 5).
Classical public key infrastructures (PKIs), most notably as X509, essentially only consider authentication information (cf. Req. 3). As information is conveyed via a fixed certificate, then if it does contain other identity related information, this information is fixed, contradicting Req. 5. For special-purpose client software, one can easily design a method to send other attributes separately, e.g., in attribute certificates, but this is not compatible with browser-only clients (Req. 2), and particularly there is no interoperable method for using varying browsers (also Req. 2).
Classical products for transferring personal data in e-commerce are form fillers. They interact deeply with browsers to drag-and-drop attributes into form fields, or use powerful tools to interpret the fields in forms. They typically only work as complicated client software and else as proxies, contradicting Req. 2. Furthermore, they do not offer full interoperability, because there is no corresponding method for the servers asking for the information.
Microsoft's Passport assumes one fixed location entity or at least only a set of entities that all have the information about users in a certain domain, i.e., there is no choice by the user or based on other business relationships, e.g., choosing the user's bank as the location entity, contradicting Req. 1.
This is an intrinsic property of this system, not something that can be changed by a different usage or embodiment, because the server is assumed to know a priori which location entity to connect to. While extensions to a so-called federation are under discussion, they are likely to have some of the other deficiencies remaining, like the following systems. Passport does not yet distinguish information that needs third-party confirmation (cf. Req. 3). Furthermore, it allows no real anonymity: There is a global user identifier, which the user can only avoid by having multiple accounts and thus by difficult management, and furthermore the location entity learns the user's communication partners (cf. Req. 4). There are also no flexible privacy policies (Req. 5). Furthermore, Passport does not allow a direct contact between the server and the location entity, which is essential for safe transfer of longer data, and this is not trivial to achieve in a federated context so that all the mentioned requirements are fulfilled.
U.S. Pat. No. 6,226,752 discloses a method and apparatus for authenticating. It does not allow a user's choice of the location entity for the same reasons as with Passport (cf. Req. 1). It only considers authentication information (cf. Req. 3) and thus no privacy policies (Req. 5) and no method for anonymity (Req. 4).
Shibboleth (http://{intentionally broken up)
followed by
                middleware.internet2.followed by        edu/shibboleth),a project of Internet2/MACE (Middleware Architecture Committee for Education), is developing architectures, frameworks, and technologies to support inter-institutional sharing of web resources that are subject to access controls. Shibboleth contains a method for finding the so-called university entity, and thus fulfills parts of Req. 1: The server asks the user for a user-friendly name of the university entity concerned and translates this using a further entity called WAYF that “knows the name and location of” each university entity. The redirection takes place to this location only for authentication, and the university entity then redirects the user back to the server with a second address of the university entity. The server uses this other address to establish a direct contact to the university entity, over which it sends a request and gets a response. This protocol does not allow local wallets (Req. 1) together with anonymity (Req. 4), in particular because the second address identifies the place of the university entity which, for local wallets, is the place of the user. There is no known method to make this address relative, i.e. saying only “on my machine”. The first address can also not be intended to be relative because the knowledge of all names and locations of local wallets would defeat the purpose. Yet another point incompatible with the combination of local wallets and anonymity is that all “assertions” in Shibboleth, i.e., the identity related information sent, must contain the domain name of the university entity. Furthermore, while Shibboleth includes privacy policies, it is not as flexible as desired (cf. Req. 5), because requests do not include privacy promises by the server. Finally, for requests where the release of the information is not pre-authorized by the user to the university entity, Shibboleth has an inefficient flow, because the browser focus (i.e., a way to ask the user) must be reestablished by a further redirect, followed by yet another redirect to the server.        
From the above follows that there is still a need in the art for an improved identity management system including the exchange protocols between persons and organizations.